Semi-Formal Test Generation for a Block of Industrial DSP

This article describes an industrial application of the Genevieve test generation methodology. The Genevieve approach [1] uses formal techniques to generate test suites for specific design behaviour. The example, which is a part of the ST100 DSP, was chosen in order to highlight real life problems such as big data structures, complex control logic, and complex environments where it is difficult to determine how to drive the complete system to ensure a given behaviour in the unit under test. 1. Genevieve Methodology Semi-formal test generation has developed from the use of “model-checking” ( [2]) to generate test suites for specific behaviours of the design under test. An “interesting” behaviour is claimed to be unreachable while supplying a property to a model-checker. If a path from initial state to the state of interest does exist a counter-example is generated by a model-checker. The sequence of states specifies a test to achieve the required behaviour. An “interesting” design state is often a corner case, which is a composition of border behaviours for different design parts or blocks. In this documents we use “corner cases” to specify a particular design state we want to test. To cope with the state explosion problem, we describe the design under test (DUT) in a simplified manner. This process, called abstraction, is shown in Figure 1. While there exist different kinds of abstract mechanism (see [3]), in this work we are concerned with three of them: 1. functional abstraction to reveal the main functionality of the design and to hide cumbersome details; the purpose of the testing becomes clear; 2. data abstraction is related to functional abstraction; data is grouped into classes or not considered at all; 3. temporal abstraction is interested in the order of events, rather than in precise timing. Ideally, the abstract description is the same as a (formal) specification of the current circuit implementation. Advantages and limitations of abstraction mechanisms are discussed in more detail while describing the tested SDU block. We use the M ALT (Modelling micro-Architecture Language for Traversal) language for abstract descriptions of the design under test (see [4]). M ALT is a VHDL based language with the usual VHDL facilities. In addition, it is possible to define test coverage models and constraints for test generation. The coverage model is basically determined by adding special attributes to “interesting” signals or variables which are referenced as coverage variables. The combinations of all possible values of coverage variables constitute the first rough set of interesting corner cases or coverage model. Each combination corresponds to a state when the abstract description is translated to an FSM model. Later in this document we use the term “state” to refer to a combination of variable values and we say that a coverage model consists of coverage states. The coverage model can be further refined by means of special functions to only test specific values of some variables or signals. The test constraints restrict the way targeted coverage states are reached. Initial and final state of the test sequence can be defined and some states or transitions can be forbidden to appear in the test sequence. It is also possible to require some state between another two states in a test suit. Finally, M ALT allows non-deterministic expressions. This is especially useful for input assignments: the designer can assign a set of values to a signal or variable. One of the values will be randomly chosen during test generation. Some other facilities, like the possibility to define the test length or the number of tests required for each coverage task, are also supported in M ALT. When the abstract description is ready it is translated to a state machine representation usable by the GOTCHA test generation tool (Figure 1). The intended coverage model is also extracted during this translation from supplementary M ALT constructions. GOTCHA (Generator of Test Cases for Hardware Architecture) is a prototype coverage driven test generator, written expressly for the Genevieve project (see [5]). The GOTCHA compiler builds a C++ file containing both the test generation algorithm and the embodiment of the finite state machine. The state machine is explored via a depth first search or a breadth first search from each of the start states. Progress reports on this initial state space exploration can be customized in a limited way. On completion of the enumeration of the entire reachable state space, a random coverage task is chosen from amongst those that have not yet been covered or proved to be uncoverable. A test is generated by constructing an execution path to the coverage task (state in our case) then continuing on to a final state. If the test length recommendation has been exceeded at this point, then the test is output, otherwise an extension path to a further final state is sought, and appended to the test. This process continues until either the test length recommendation is exceeded or final state reached has no path to a further final state. If the randomly μ